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ABSTRACT 

This paper will present the Space Station Biological Research Project U “ 

Facility (UOF) architecture and development strategy. A major element of the UOF at NASA Ames 
Research Center, the Communication and Data System (CDS) will be the primary focus o e 
discussions. 

CDS operational, telescience, security, and development objectives will be discussed along with CDS 
implementation strategy. The implementation strategy discussions wi l inclucfc^ Object Onen ed 
Analysis & Design, System & Software Prototyping, and Technology Utilization. A CDS design 
overview that includes: CDS Context Diagram, CDS Architecture, Object Models, Use Cases, and User 
Interfaces will also be presented. 

CDS development brings together “cutting edge” technologies and techniques such as: object 
oriented development, network security, multimedia networking, web-based data distribution, JAVA, 
and graphical user interfaces. Use of these “cutting edge” technologies and techniques translates 
directly to lower development and operations costs. 


INTRODUCTION 

SSBRP’s mission is to design, develop, validate, and deploy a facility class payload to perform non- 
human life science experiments on the International Space Station (ISS). The operation of the 
facility class payload will be accomplished at the UOF at NASA Ames Research Center, Moffett 
Field, California, USA. The principal communication and data processing element of the Ames UU1- 
is the CDS which will be featured in this paper. 

Figure 1 presents the CDS communication infrastructure for planning, commanding, telemetry 
processing, and data distribution. Planning consists of pre increment launch planning and on-orbit 
activities planning, using CDS planning software and planning systems at other NASA centers^ 
External planning systems include the Payload Planning System (PPS) Payload Data Library and 
Payload Information System at Marshall Space Flight Center (MSFC) and the Space Station Payload 
Processing Facility at Kennedy Space Center (KSC). 

Commanding is accomplished through an interface with the Payload Operations Integration 
Function (POIF) at MSFC and the Space Station Control Center at Johnson Space Center (JSC), 
Both the MSFC and JSC facilities verify the commands integrity and then integrate the command 
with other commands for uplink to the ISS. 

Telemetry data originates in the SSBRP on-orbit equipment and is transported to CDS via die ISS 
Communication and Data Handling System and through the MSFC Payload Data Services System. 
CDS processes the SSBRP data (includes: experiment data, engineering data, and digital video) as 
real-time broadcast data/video and also stores the data/video for future retrieval and analysis. CDS is 
required to store, as a minimum, the last 120 calendar days of telemetry data. 

Details of the commanding and telemetry architecture may be found in SpaceOps98 paper 2m006 
“End-to End Data System Architecture for the Space Station Biological Research Project . 
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Figure 1 - SSBRP Communication Infrastructure 


d * a * nd Yide ,° distribution to researchers not resident within the Ames UOF u/iii tv» 


CDS DEVELOPMENT OBJECTIVES 




Table 1 - CDS Mission Requirements (Summary) 


Science 

Support Multiple Experiments & Researchers 
Provide Habitat Environmental Control 
Support Remote Experiment Monitoring 
Support Specimen Sharing 
Provide Experiment Data Accessibility 

Operations 

Perform Concurrent Operations(24hrs x 7days) 
Perform Integrated Planning 
Provide Real-time Data Distribution 
Provide Remote Researcher Presence at UOF 
Perform Integrated Logistics 


Security 

Support Distributed Operations 
Provide Data Partitioning by Researcher 
Perform Internet Data Distribution 
Implement Security Policy 
Provide Computer/Network Security 

Engineering 

Provide Equipment Monitor & Control 
Support Equipment Diagnostics 
Provide Logistics & Inventory 
Support Maintenance 
Perform Development Verification 
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The CDS development team has (and will continue to) traded-ofT one-time development costs versus 
operational costs as the means to increase operational efficiency. To say this another way, CDS is 
being developed to eliminate as many operator functions as possible without jeopardizing 
crew/vehicle/payload safety or mission success. CDS is also developing the user interface to be as 
intuitive as possible to reduce operator/user training and skill requirements. Figure 2 is an example 
of the user interface strategy developed during a CDS prototyping activity. The user interface 
strategy presented illustrates how a user would select an alarm (on the left most display) and navigate 
to the appropriate display for the user to initiate corrective action (on the right most display). Please 
also note the integration of data and video on the right most display. 



Figure 2 - CDS User Interface Strategy 


IMPLEMENTATION STRATEGIES 

The overall implementation strategy for CDS was to identify and use wherever possible “cutting 
ed^e“ technologies and techniques currently available. With the projected ISS life span of 10 years 
or*more, the CDS approach minimizes obsolesce of today’s technologies without the need to invent 
technology. Good examples of these “cutting edge” technologies are: Object Oriented v^ialysis & 
Desim, JAVA, multimedia data communications, network security, Internet-based data distribution, 
video multicasting, Computer Telephone Integration, and object/ relational database technologies. 

Along with the “cutting edge” technologies mentioned above, CDS is being developed using an 
Internet-based development strategy. The Internet-based environment is currently under 
development and has die overriding goal of providing accurate and up to date access to all CDS 
development products. CDS’s Internet environment includes integrated off-the-shelf products for 
system/ software modeling, configuration management, problem reporting, and product distribution. 
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An early version of this Internet-based environment was used to perform the CDS Object Oriented 
Analysis Review (earlier this year). Reviewers were asked to perfonn their assignments with browser 
access to CDS documentation and object oriented models via the Internet attheir local facility 

“ d T e ,SSUCS WCre ^ lected via Web Pages and made available via the same Web 
pages to any interested reviewer or development team member. 


OBJECT ORIENTED ANALYSIS AND DESIGN 


CDS development team originally 
selected Rumbaugh’s Object 
Modeling Technique (OMT) and 
Jacobson’s Use Cases for CDS. 
During the period leading up to the 
initial CDS review, OMT and Use 
Cases were combined along with 
the Booch method to form the 
Unified Modeling Language 
(UML). UML was also adopted as 
a standard by the Object 
Management Group in 1997. 

UML, the next generation object 
oriented modeling language solved 
some of the inherent issues of 
combining independent, but 
complemetary, techniques. UML 
was adopted by the CDS 
development team with a minimal 
amount of convesion effort during 
preparation for the CDS Object 
Oriented A nal ysis Rev iew . 

Figure 3 is the CDS Context 
Diagram and presents the users 
(people) and systems (POIF, PPS, 
etc.), along with data flow direction 
(arrowheads), that define the 
environment in which CDS must 
execute. Users and systems 
interacting with CDS are considered 
actors and are represented by UML 
as stick- people in Figures 3 and 4. 

Figure 4 presents the Use Cases for 
each actor during the CDS 
Operations Mode. CDS has 
multiple modes each with their 
equivalent Figure 4. The ovals in 
the CDS Operations Mode Use 
Case represent specific behaviors of 
CDS. These behaviors are then 
detailed individually to specify the 
system operational requirements. 



Figure 3 - CDS Context Diagram 
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Figure 4 - CDS Operations Mode Use Case 
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Using UML has allowed the CDS developers to specify in a very clear and simple r e P r esentaa 
the functional capabilites to the “real customers” of CDS, the users. A development benef t 
relatively easy translation of these system behaviors to a CDS architecture. 


UML usage for CDS is detailed further in SpaceOpsSS paper 4c00; i “SSBRP Communicaation & 
Data System Development using the Unified Modeling Language (UML). 


Software prototyping and object oriented techniques are very compatible because both focus on the 
user^needs for the system under definition. The CDS development team has produced a number of 
software prototypes prior to the CDS Object Oriented Analysis Review; and, plans to continue the 

prototyping effort. 


TECHNOLOGY UTILIZATION 

CDS implementation strategy has specified a number of technologies required during development 
Some^fthTse^echnologies'are off-the-shelf while others require a developmeai effort. A short 
discussion of some of the more significant technologies follows. 

In moving from the more costly point-to-point communication approaches to an Internet-based 
communication solution security becomes a major concern. CDS 1S ^ 

and data security from the outset of CDS development as insurance that the developed system win 
meet orVxceed externally specified as well as imernally generated seennry reqmrements. The 
security component of CDS will be built in, not patched on. 

Anvone who has purchased a safe recently will understand, security is measured by time required to 
teK ffiveS?any safe can be compromised. Therefore network, computer, and data security 
have a continuing security administration component, not just a development component. 

Obviously CDS security implementation details will not be discussed in any open ^ 

Security Policy development approach is described in SpaceOps98 paper 5d004 Security 
Multimedia Space Data Distribution Over The Internet”. 

The non-human life sciences research community supported by SSBRP relies heavily on the 
experiment’s specimen for data. Although some biotelemetry data are expected to be available from 
fmolamed^ sensors for the most part high resolution still-frame and motion-video will be used to 
Lnhance^ The researchers knowledge of the state of the experiment. Motion-video also allows the 
UOF ground operators to reduce crew time (very limited on-orbit resource) required to meet 
specimen well-being requirements. 

PYneriment and operations multimedia data, that include still-frame and motion-video, will be 
ca^t dighfzeSron,^ on-orbit'. Consequently, CDS doe. hot .need | an analog vjdeo 
handling or distribution element within the UOF or to the remote researcher faci y. . .. 

stored and distributed in compressed form then uncompressed at the point of display either within 
the UOF or at the remote researchers facility. Multicast network protocols are being consi ere 
both internal CDS and remote researcher multimedia data distribution. 

Reducing the staff required to process the magnitude of data captured on-orbit and returned to the 
UOF was a major consideration in establishing an Internet-based toadist nbution 
established the “come and get the data at your convenience strategy for the remote researener 
The intent of this strategy was to not only reduce the staff required to produce reques e 
products, but to reduce the pre-launch planning as well. 

As an additional benefit to this approach, CDS can animate a 

UOF and at the remote researchers facility using JAVA and related technologies. This a 

the CDS development team to leverage internal UOF software development with external data 

distribution software and remain platform independent. 
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CDS DESIGN OVERVIEW 
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The CDS development team 
selected FDDI as the backbone and 
subnet structure because of FDDI’s 
bandwidth for multimedia 
networking and the availability of 
FDDI network cards for CDS 
workstations and servers. The 
FDDI backbone, Flight Operations 
Area subnet, and system 
development subnet have been 
implemented for two years and 
support current CDS prototyping 
and development activities. 

The demarcation point to the 
NASA Integrated Support Network 
(NISN) for Ames is housed in the 
Gateway Building. Connectivity is 
then extended to the Flight 
Operations Area subnet and other 
supporting subnets using the CDS 
backbone. 



Figures - CDS ’s Isolated FDDI Network 


CDS is in the initial design phase of the development life cycle. Since CDS will sunnort SSRRP nn 
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interface. The goal is to reduce operator staffing requirements using the same concept used in 
system development where doubling the work force does not half the development time. 



Currently the most well-defined of the trilogy of CDS functions is the telemetry processing CDS 
receives Consultative Committee for Space Data Systems (CCSDS) packets from the ISS via the 
Payload Data Services System at MSFC. At CDS receipt of the CCSDS real-time data packets, the 
packets are processed; and, then only forwarded to the operator positions requiring the specific data 
Additionally, the data is forwarded to any researcher currently on the Web server that requested the 
data. This distribution scheme includes multicast digital video. The real-time CCSDS data packets 
are also forwarded to a database system for later retrieval and analysis. 


CCSDS data packets that arrive at CDS out of sequence, or were stored in transit, are sent directly to 
the CDS database for later retrieval. Since CDS uses data generation time as the storage ordering 
mechanism, CDS inherently time orders all stored data for future access. Retrieval of stored 
telemetry data may be accomplished by a CDS operator and/or researcher resident in the UOF or at 
their remote facility. 


CDS commanding and planning functions are still in the definition stage and therefore not presented 
here. 


CONTINUING ACTIVITIES 

A series of CDS Object Oriented Design Reviews are scheduled to begin late this year and continue 
into 1999 In parallel to the software design process, the CDS network design is being completed 
along with finalizing the CDS Security Policy. Concurrently to the software and network design 
activities, the CDS development team members will continue to evaluate technologies that may be 
applicable to CDS and implement prototypes as appropriate. 
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